The present invention relates to an operating system of a computer, and in particular, to an operating system generation method in which input/output device control programs can be incrementally added to an operating system.
An operating system (to be abreviated as an OS herebelow) includes a basic portion of the operating system (to be abbreviated as a kernel herebelow) serving basic functions of the operating system such as a process management and a memory management and input/output device control programs (to be referred to as input/output device drivers herebelow) for controlling input/output devices connected as peripheral devices. An operating system includes only one kernel, whereas a plurality of drivers are provided in association with the respective input/output devices.
In general, as the number of input/output devices connected to the computer increases, there appears an increased number of kinds of drivers. In addition, since different types of input/output devices are connected to the various computer systems for the respective users, the combination of the drivers included in the operating system varies between the user systems. Consequently, it is required to incorporate the driver into the operating system depending on the hardware constitution of the user system.
When a driver is incorporated into an operating system so as to actually execute the operating system for the control of the input/output devices, there arises necessity of the mutual reference between the driver and the kernel in the operating system. The mutual reference is effected through three types of operations as follows.
(1) Routine call from the kernel to the driver PA1 (2) Routine call from the driver to the kernel PA1 (3) Reference to data from the driver to the kernel PA1 (1) Special compiler and linkage editor capable of generating a plurality of segments and of retaining symbolic names also after the processing. PA1 (2) Hardware causing a linkage interruption when a symbolic name is referenced.
When a user program issues an input/output request, the kernel calls a driver routine associated with the request, which corresponds to (1) above.
On the other hand, at an execution of an input/output operation, the driver routine calls the kernel routine to effect processing which can be controlled only by the kernel, which corresponds to (2) above. In addition, the driver routine references data managed by the kernel such as an address of data and a data length of data associated with the input/output operation, which corresponds to (3) above.
When incrementally adding a driver to the operating system, the mutual reference between the kernel and the driver to be added is required to be enabled at an execution time. In general, a source program of the kernel or the driver is described by use of a symbolic name also in a case of the mutual reference. On the other hand, in a load module at an execution, all symbolic names are required to be translated into absolute addresses. When incorporating a driver into the operating system, there arises a problem of a method to translate the symbolic names to be subjected to the mutual reference between the kernel and the driver, which is referred to as a problem of an address solution herebelow.
Heretofore, there have been employed two methods of incorporating a driver in an operating system, namely, a static link method and a dynamic link method.
FIG. 12 shows the static link method in which a kernel 40 is calling a driver 41-m (with a driver name DRIVER m). When source programs 43 including the kernel 40 and a plurality of drivers comprising the driver 41-m are linked with each other by use of a static linkage editor 44, a load module 47 is produced. In the load module 47, an address (MOO) of DRIVER m is arranged in a portion (an operand of a CALL instruction in the kernel 40) which calls the DRIVER m. As described above, in the static link method, the address solution between the kernel and the drivers is achieved at a link-edit phase for the following reasons. That is, since all the necessary drivers and the kernel are linked with each other at a time by means of the linkage editor 44, a symbolic name (DRIVER m in this example) of each driver associated with a mutual reference and an absolute address (which is MOO in this example and is not necessarily a physical address) of the driver can be completely obtained by the linkage editor 44.
The dynamic link method has been described in pages 173 to 176 of the "Operating Systems" written by S. E. Madnick, J. J. Donovan and published from McGraw-Hill in 1974. Referring now to FIG. 13, the address solution of the dynamic link method will be described.
In the dynamic link method, the kernel 40 and the drivers 41 is not transformed into a load module by a dynamic linkage editor 48, namely, there are produced two segments 49 and 50, which are independent of each other.
In this configuration, a portion which calls "DRIVER m" in the kernel 40 keeps a symbolic name "DRIVER m" also after the processing of the dynamic linkage editor 48 is finished. Actually, although the portion which calls "DRIVER m" is included in an application program and other drivers, it is assumed here for simplicity of description that "DRIVER m" is included in the kernel 40 or 49. When CALL "DRIVER m" is executed in the kernel 49, a linkage interrupt processing program 51 of the kernel 49 is initiated. The linkage interrupt processing program 51 is provided with a table 52 for storing therein a symbolic name of each driver and an address of the main memory where each driver is to be allocated, each driver being associated with the associated address. Each time a driver is called by the kernel 49, the linkage editor 48 solves an address for the driver to load the driver onto the main memory. Furthermore, in a portion of the table 52 associated with the driver, a symbolic name thereof and the address of the main memory are stored. As described above, when CALL "DRIVER m" is executed in the kernel 49, the linkage interrupt processing program 51 is initiated. Subsequently, the linkage interrupt processing program 51 searches the table 52 to determine whether or not "DRIVER m" is stored therein. In the initial state, the table 52 is not loaded with any significant data. Consequently, the linkage interrupt processing program 51 transfers an instruction to call "DRIVER m" from an auxiliary storage (e.g. a magnetic disk unit) to a driver beforehand incorporated in the kernel 49 for the auxiliary storage.
The DRIVER m thus called solves addresses, for example of a routine call instruction in the "DRIVER m" and is then loaded in the main memory at an address "MOO". The "DRIVER m" is thereafter executed. In the processing procedure, the address "MOO" and "DRIVER m" are written in the table 52. In a case where the kernel 49 executes again CALL "DRIVER m", the kernel 49 first passes the CALL instruction, namely, CALL "DRIVER m" to the linkage interrupt processing program 51, which then searches the table 52 so as to transfer the associated address "MOO" to the kernel 49. Thereafter, the kernel 49 calls the "DRIVER m" by use of the address "MOO".
In this fashion, according to the dynamic link method, the symbolic name of each driver is kept retained up to an execution so as to solve the address at the execution.
The driver incorporating method according to the prior art technology above is attended with the following problems.
In general, for the input/output devices connected to the computer, it is desirable for the user to arbitrarily configure combinations thereof depending on a utilization state of the computer. Moreover, a unique driver produced by the user is desirably added to the existing operating system.
However, the linkage editing of the kernel and the drivers in the form of source programs as described above is conducted on the side of the operating system supplier and hence only a load module in which all addresses have been solved is passed to the user because it is not favorable for the supplier side to provide the user with the source programs of the kernel and drivers. In actual cases, it is almost impossible for the user to acquire these source programs.
In particular, according to the static link method, described with reference to FIG. 12, since the source programs of the kernel and drivers are not sent to the user, the user cannot arbitrarily add a new driver to an operating system produced as a load module by use of the static linkage editor 44 for the following reasons. That is, in this method, the linkage editor 44 translates, in the link edit operation, symbolic names subjected to the mutual reference between the kernel 40 and the drivers 41 into addresses so as to generate an operating system 49 as an executable load module. In other words, in order to add a new driver to the operating system 49 in the load module format for which the address solution has already been completed so as to achieve the address solution for a symbolic name to be subjected to the mutual reference thereafter, it is necessary to prepare a linkage editor having such a new function. However, in the present stage of technology, there does not exist such a special linkage editor.
On the other hand, according to the dynamic link method described with reference to FIG. 13, the address solution is accomplished on the symbolic names for which the mutual reference is effected between the kernel 40 and the drivers 41 during the execution of the operating system 49; in consequence it is possible to add a driver to the operating systems 49. However, in order to implement this method, the following two items are essential as described above.
In consequence, in an ordinary computer not provided with such special software and hardware, the dynamic link method cannot be adopted.
As described above in the driver incorporation method of the prior art technology, there exists a problem that a driver cannot be added to the operating system depending on the change in the kind of the input/output device connected to the computer.
Furthermore, in a case where a driver produced by the user can be freely incorporated into the operating system, there arises a possibility that an incomplete driver including errors may be incorporated into the operating system for execution. In such a case, the drive including the errors operates in a special state. As a result, it can be considered that an invalid memory access and/or a system runaway may take play, which possibly leads to a system down.